Some network components, such as firewalls, network address translators (NATs), intrusion detection systems (IDSs), intrusion protection systems (IPSs), deep packet inspection (DPI) devices, wide area network (WAN) optimization devices, layer 7 traffic accelerators, and server load balancers (SLBs), process a diverse mix of network traffic in operation. Accordingly, before deploying such equipment in a live network, it is desirable to test the equipment with a traffic simulation that is representative of the traffic mix that the equipment will handle upon deployment. For example, it may be desirable to test a firewall by repeatedly sending traffic from different applications through the firewall.
In today's world with the advancement of Internet and smart phones, we are seeing an explosion of Internet based applications. These applications run on multiple machines where many of them are servers and mainly serving requests sent by associated application clients. Notably, all of these applications are not defining their own transport, but instead use a common layer 4 to layer 7 transport to exchange application specific messages. One such common transport is HTTP, which is associated TCP listen port 80. Similarly, many secured applications may exchange messages using HTTPS via the listening port 443. Examples of applications running HTTP or HTTPS are Facebook, Google Maps, Twitter, and the like. Even though all of these applications/protocols are running on top of HTTP, each of the messages exchanged adhere to completely different formats known only to the application client and server. Namely, a common server cannot service the requests sent by a different application client since messages sent by different clients cannot be parsed using a common set of rules.
Normally, the servers for different applications run on different hosts having different IP addresses even though they share the same transport layer port (TCP port). Specifically, the IP address and port combination uniquely points to a single application server which exactly knows how to parse messages associated with a particular application. In a network traffic emulation environment, things become further complicated since there is a need to emulate multiple application servers on a single host. One possible solution to this problem is to implement complete application servers (e.g., a Google server, a Facebook server, a YouTube server, etc.) on the same emulation device. Another possible solution would be to implement a single monolithic server hard coded to recognize and respond to messages from different applications. However, neither possible solution is scalable.
Accordingly, there exists a long felt need for methods, systems, and computer readable media for classifying application traffic received at a network traffic emulation device emulating multiple application servers.